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C lient/server database applications must frequently address the need to enforce 
access and usage constraints for various classes of users. We are all familiar 
with the Human Resources example where everyone can view (SELECT) the basic 
columns of the Employee table, but only managers can view (SELECT) the Salary 
column, and only HR administrators can change (UPDATE) the Salary column. 


We're also familiar with the basic mechanisms 
(views and privileges) that Oracle provides to han- 
dle these situations from the database perspective. 
As we'll see, however, these basic mechanisms have 
their limitations. Moreover, from an application 
perspective, there is no standard mechanism by 
which we can selectively hide the Salary field on 
the “Employee Search” form of our HR applica- 
tion based on who the current user is, or eliminate 
access to entire chunks of application functionali- 
ty (dealing with salary administration, for 
instance). This article presents the design of a secu- 
rity system that uses Oracle’s database roles to 
address both these issues and to simplify effective 
security handling in client/server applications. 


Strategies 

Discussion of what security strategy to adopt usual- 
ly focuses on a choice between a front-end (client- 
based) strategy and a back-end (server-based) strat- 
egy, according to which “end” is primarily respon- 
sible for enforcing security. The choice is not really 
binary, however, as there are a variety of possible 
strategies, and all involve both ends to some degree. 


The “extreme” front-end strategy grants database 
privileges to all application users (or to PUBLIC) 
on all objects used by the application at the least 
restrictive level used anywhere by the application. 
That is to say, if the application ever needs to 
update a certain table, then a// application users 
are granted UPDATE privileges on that table. If, 
in fact, only certain users are eligible to update the 
table, or if it’s appropriate to update the table only 
under certain circumstances, it’s up to the applica- 
tion to enforce these more restrictive conditions. 


Apart from the fact that this strategy inevitably 
increases application complexity, it also leaves open 


the possibility that any privileged user might gain 
access to the database objects in question via some 
means (Access, Paradox, SQL*Plus, etc.) other than 
the controlled application, and thereby, in the 
absence of appropriate application enforcement, do 
something undesirable to the database, whether 
intentionally or not. 


All other strategies give more responsibility to 
the database. One approach is to identify the 
specific access requirements for each application 
user and to grant appropriate database object 
privileges to individual users on that basis. This 
still leaves open the possibility that a user privi- 
leged to perform a certain operation under appli- 
cation control might do something undesirable 
through some other means. 


Role Playing 

A generalization of the user-based approach takes 
advantage of Oracle voles. Distinct roles are created 
for various classes of users (e.g. managers, HR 
administrators), and database object privileges are 
granted to the roles rather than to the individual 
users. From a security point of view, this approach 
suffers from the same defects as the user-based 
approach. It’s just more convenient to administer. 


Oracle provides the further capability, however, to 
selectively enable or disable a role, as well as to enable 
by default any or all of the roles assigned to a user. 
Roles assigned to classes of users as described above 
must necessarily be enabled by default in order to be 
useful to all applications. This opens up the same old 
security hole. 


An alternative is to create an application role for each 
application that uses the database. Such a role is not 
enabled for any user by default, but is specifically 
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enabled at run time by the application that uses it. Just those database 
object privileges appropriate to the application are granted to the applica- 
tion role, and just those users — or classes of users, in the form of other 
roles — authorized to use the application are granted the application role. 
Since the role is enabled only during the execution lifetime of the appli- 
cation, we avoid the problem of inappropriate uncontrolled access. 


(Or “innocent” inappropriate access, at least. Nothing about applica- 
tion roles as such — even those with passwords — prevents a deter- 
mined attacker with some legitimate database privileges in the context 
of application A from writing his own application B that masquerades 
as A and then attempts to misuse the privileges granted to A.) 


Yet application roles take only one step in the direction we want to go. 
In the case where not every application user is authorized to do every- 
thing the application can do, we would have to define distinct appli- 
cation roles for the different classes of application users, grant the 
appropriate privileges to each role, and have the application enable the 
appropriate role as needed. 


This addresses the security issues, but may be difficult to set up and 
administer. And integrating application behavior with database privi- 
leges and controlling access to functionality within the application 
appropriately are still left to be dealt with in an ad hoc manner, pro- 
viding ample opportunity for error. 


Make it Clear 


What we need to do is make explicit the relationships between user 
identity, application functionality, and database object privileges. Not 
only can we use this information to customize application behavior at 
run time, but we can also use it as the basis for creating all the 
user/usage-specific database roles we need — completely automatical- 
ly. Let’s see how this might be done. 


What follows is a design for a system that facilitates defining privileges 
for application functionality and database objects at as fine a level of 
granularity as may be required, and that allows applications to make 
use of this information at run time with a minimum of coding effort. 


Specifically, the system: 

m makes explicit the notion of a usage “right,” or privilege, for any 
application element (e.g. form, button, method, menu item; any- 
thing an application needs to control). 

™ provides a mechanism to associate database object privileges 
(INSERT, SELECT, UPDATE, UPDATE(column), DELETE, 
EXECUTE on any table/view/procedure) with application privi- 
leges in a single security database. 

™ provides a mechanism whereby an application can easily deter- 
mine at run time what privileges are available to the current user, 
and dynamically activate just those database object privileges 
appropriate to the application context at hand and the current 
user's application privilege in that context. 


The system consists of an administration application and a run-time 
component to be imbedded in, or loaded by, applications using secu- 


Table Name 


Key 
User_Role i 


User [ID 


App_Privilege | Application User Role Application 
Name Item 


DB_Privilege 


Figure 1: Summarizing the security system. 


Application User Role Database 
Name Role 





Application Application Application Database 
Name Item Privilege Object 


rity services. The security system data is itself stored in the form of 
database tables. These are summarized in Figure 1 and described in 
detail below. An example follows. 


The fundamental context for all privileges is the Application, identi- 
fied by its name. Associated with each Application may be any num- 
ber of User Roles, also simply identified by name. The User_Role 


table associates application users with User Roles as required. 


The App_ Privilege table associates with each Application/User Role 
combination any number of Application Privileges assigned to partic- 
ular Application Items. Privileges too are simply names, invented at 
the discretion of the designer. They might include Create, Insert, 
Read, Select, Update, Change, Delete, Execute, View, Manage, etc., 
but are not limited to these or to any fixed set. An Application Item 
is any notional application element (form, menu, menu item, sub-sys- 
tem) whose availability and/or usage an application wishes to control. 


The DB_Privilege table associates with each role/item/privilege com- 
bination, any number of Database Privileges assigned to particular 
Database Objects. A Database Privilege is any privilege recognized by 
the DBMS the application uses, and a Database Object is any object 
on which the DBMS recognizes privileges. 


From this information, as formulated by the application designer, the 
security administration application automatically synthesizes database 
object privilege groups (Oracle roles), records their (generated) names 
in the security tables, and creates (or updates) them in the DBMS. 


For example (see Figure 2), consider a highly simplified human 
resources application. The application defines three user roles: 
Administrator, who can do everything; Manager, who can view all 
information, but change nothing; and Viewer, who can only view the 
organizations management structure. 


Named privileges on designated application elements are assigned to 
the user roles as in the App_Privilege table (see Figure 3). Remember 
that the Database Role information is not entered by the security sys- 
tem user, but is generated automatically by the system. 


The database object privileges required to support the various applica- 
tion privileges in the designated application contexts are specified in 
the DB_Privilege table (see Figure 4). With this information in hand, 
the security system defines roles and grants privileges as in Figure 5. If 
entering the information into the tables in Figure 2 through 4 seems 
tedious, consider that it saves devising, entering, and maintaining what 


appears in Figure 5. And this is for a highly simplified example. 


On application startup, the security run-time component initializes itself 
by retrieving from the security tables the information necessary to pop- 
ulate a private data structure that associates each application item for the 
application at hand (as defined at design time) with the present user’s 
application privilege and, if applicable, database role for that item. 
Caching this information locally makes further calls to the security com- 
ponent in the application very fast. 

Attributes While the application is running, 
as control passes into each desig- 
nated application context, the 
application, without concern for 


Application Database 
Privilege Role 


any of the underlying information, 


Database 


including the name of the role, can 
Privilege 


request the security system to 


enable (SET ROLE) the appropri- 
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Table: User_Role 
Application Name Database Role 


HR Admin Administrator 


HR Admin 
HR Admin 


Table: App_Privilege 


Application User Role Application | Application | Database 
Name Item Privilege Role 


HR Admin | Administrator | Salary 
Guidelines 


HR Admin Salary Grid | Modify | OBJOO1 


HR Admin | Administrator | Employee Modify OBJO02 
Summary 


HR Admin Modify | OBJ003 
OBJ004 


HR Admin Employee View Salary ome | 
HR Admin 0B1005 


APPOO1 
APPOO02 
APPO003 
APPO03 


Laszlo 


Fumiko 


Marthe 


Summary 


HR Admin _ | Viewer Employee View OBJ006 
Summary 
Table: DB_Privilege 


Database 
Privilege 


MODIFY 
MODIFY 


Application | Application | Application Database 
Name Item Privilege Object 


HR Admin _| Salary Grid Modify SALARY 
Employee 


HR Admin Modify EMPLOYEE 
Summary 
Employee Modify SALARY 
Summary 


Employee 


HR Admin View EMP_MGRVIEW | SELECT 
Summary Salary 
Employee View EMP_EMPVIEW 
Summary 


Figure 2 (Top): The User_Role table. 

Figure 3 (Middle): The App Privilege table. 

Figure 4 (Bottom): The DB Privilege table. To reduce the size of the 
example, the privilege name MODIFY is used in place of the three distinct 
privileges INSERT, UPDATE, and DELETE. 


HR Admin SELECT 


HR Admin SELECT 


SELECT 
SELECT 
SELECT 





ate database role for the context at hand. In this way, the user receives 
appropriate privileges on just those database objects relevant to the con- 
text at hand, and just for the time during which access is required (pro- 
vided the application notifies the security component when control pass- 
es out of the context in question). 


To adjust its own behavior (to disable a button or menu item, for 
example), the application can ask the security system to supply (as a 
string or list of strings) the user’s application privilege(s) in the current 
context, on the basis of which the application can take appropriate 
action. In a GUI application, database roles can easily be made to 
track the active window (form) by putting the appropriate security 
system calls — enableRole(context), disableRole() — in the 
FormActivate and FormDeactivate events, respectively. 


CREATE ROLE app001; /* Administrator */ 
GRANT app001 TO laszlo; 


CREATE ROLE obj001; /* Salary Grid, Modify */ 
GRANT INSERT, UPDATE, DELETE ON salary TO obj001; 
GRANT 0bj001 TO app0oo1; 


CREATE ROLE obj002; /* Employee Summary, Modify */ 
GRANT INSERT, UPDATE, DELETE ON employee TO obj002; 
GRANT SELECT ON salary TO obj002; 

GRANT obj002 TO appoot; 


CREATE ROLE 0bj003; /* Organization, 
GRANT SELECT ON employee TO o0bj003; 
GRANT INSERT, UPDATE, DELETE ON emp dept TO obj003; 
GRANT INSERT, UPDATE, DELETE ON department TO obj003; 
GRANT obj003 TO appooi1; 


Modify */ 


CREATE ROLE app002; /* Manager */ 
GRANT app002 TO fumiko; 


CREATE ROLE 0bj004; /* Employee Summary, View Salary */ 
GRANT SELECT ON emp_mgrview TO 0bj004; 
GRANT 0bj004 TO app00d2; 


CREATE ROLE o0bj005; /* Organization, View */ 
GRANT SELECT ON employee TO obj005; 

GRANT SELECT ON emp dept TO obj005; 

GRANT SELECT ON department TO obj005; 

GRANT o0bj005 TO app0d2; 


CREATE ROLE app003 
GRANT appOO3 TO jiri; 
GRANT app003 TO marthe; 


/* Viewer */ 


CREATE ROLE obj006; /* Employee Summary, View */ 
GRANT SELECT ON emp _empview TO 0bj006; 
GRANT obj006 TO app00d3; 


Figure 5: Defining roles and granting privileges. 


Conclusion 

Thanks to Oracle’s flexible and powerful roles, the answer to the ques- 
tion of which system component should be in charge of client/server 
security turns out to be neither the client nor the server, but the secu- 
rity itself, that is, the security information. 


By explicitly and systematically taking account of the relationships 
between application objects and database objects, synthesizing this infor- 
mation in the form of roles and then using the same security database to 
control both client and server, we achieve two important benefits: 

m We facilitate the development, testing, and maintenance of any 
client/server application by reducing and simplifying application 
code and by completely eliminating the need to write any securi- 
ty-related database code. 

m We improve the overall software development process — facili- 
tating development and testing of all client/server applications 
and improving predictability and repeatability — by providing a 


common framework and reusable components. 
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